On aspectualizing component models

aspect RoleBasedAuthorization { protected AuthorizationService as = ...; abstract pointcut authorizedMethods(); protected before() : authorizedMethods() { //authorization check implementation goes here } } aspect OrderProductAuthorization extends RoleBasedAuthorization { pointcut authorizedMethods() : call(public void Order.*) || call(public * Product.*}; } Figure 9. Aspect Reuse via Abstract Aspects To apply authorization checks to Order and Product in Fig. 9, we don’t change RoleBasedAuthorization but implement the pointcut of OrderProductAuthorization instead. The pointcut now also denotes those points in the execution of the program when instances of the Product class receive messages in addition to the points when instances of Order receive messages. OrderProductAuthorization thus fulfills a similar role as a binding in [12, 13]. Employing abstract aspects to increase aspect reusability in AspectJ has the following drawbacks: First, using concrete aspects as connectors may easily lead to a complex and bloated aspect hierarchy, which is hard to understand, extend and maintain. Second, when we employ an abstract aspect, it is still necessary to have the aspect source code available as well as being able to understand and modify AspectJ code in order to apply an authorization service to base objects. As pointed out in [13] and [5], the process of binding an abstract aspect to a concrete base object via inheritance requires sophisticated programming skills and is by no means straightforward. Third, applying abstract aspects is limited especially if aspects define aspect instance state, as discussed in detail in [13] and [5]. EJB technology makes it certainly much easier to apply infrastructural services to an Enterprise JavaBean. If Order and Product were EJBs, we would just deploy the two EJBs together with their deployment descriptor. The container would then automatically apply the appropriate services. To modify authorization checks, we simply edit the deployment descriptor. There is no need to programmatically change any container or EJB code. In fact the container’s interceptor framework is neither specified by the EJB specification [16] nor is the source code of any commercial EJB container available (see Sec. 2.1 for discussion). 3.3.2. Deploying Aspects AspectJ requires that aspects are applied to base objects at design time (base object classes are hard coded in pointcuts and aspects are compiled together with the base object code). As a consequence, the application of infrastructural services to classes like Order and Product Copyright c © 2000 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2000; 00:1–6 Prepared using speauth.cls 14 R. PICHLER K. OSTERMANN M. MEZINI cannot be changed at deployment time. Using EJBs, however, infrastructural services are applied at deployment time via the deployment descriptor. Some J2EE application servers even allow deployment descriptor changes in production (hot deployment). Delaying the application of infrastructural services until deployment time increases the flexibility and reusability significantly. Besides the useful delay of the deployment to runtime, this also enables to choose the actual implementation of an aspect at runtime, i.e., we could choose the transactionor persistence implementation at runtime. In AspectJ, however, there exists a static link between a particular aspect implementation and the base classes, and we have no means whatsoever to change this link without modifying code (which is bad), and even if we come to terms with code modification, this cannot be done after compile time.